home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93a.txt / 000101_icon-group-sender _Thu Apr 1 12:13:34 1993.msg < prev    next >
Internet Message Format  |  1993-04-21  |  1KB
  1. Received: by cheltenham.cs.arizona.edu; Thu, 1 Apr 1993 11:39:45 MST
  2. Date: Thu, 1 Apr 93 12:13:34 EST
  3. From: Paul_Abrahams@MTS.cc.Wayne.edu
  4. To: icon-group@cs.arizona.edu
  5. Message-Id: <616446@MTS.cc.Wayne.edu>
  6. Subject: Error level from MSDOS Icon
  7. Status: R
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9.  
  10. Here's a minor but annoying problem that shouldn't be too hard to fix at
  11. the next update of MSDOS Icon.  If there isn't enough extended memory for
  12. icont to operate, it quits (as I would expect it to).  However, if
  13. stderr has been redirected to a file, the generated error messages never
  14. make it to that file, probably because stderr hasn't been closed
  15. properly.  In addition, the error level isn't set nonzero.
  16.  
  17. I came across this behavior because I was setting up an automatic call
  18. to Icon from an editor.  There wasn't enough extended memory but all the
  19. indications of the problem were lost (since the editor didn't display the
  20. execution screen).  The editor thought that icont had ended normally and
  21. had produced no error file.
  22.  
  23. I'd be quite happy if icont merely set the error level nonzero if it
  24. aborts because of insufficient memory or a similar condition.  I
  25. wouldn't want it to set the error level nonzero just because the source
  26. program has errors.
  27.  
  28. Paul Abrahams
  29.